dev: generated checklist of DF defect mitigations for release review - #5941
Alistair-Afton wants to merge 3 commits into
Conversation
DFHack works around a number of defects in DF itself, and those mitigations need to be re-reviewed whenever Bay 12 releases a new DF version. Marking them with DF-MITIGATION: comments where they live keeps the checklist from drifting, and ci/list-df-mitigations.py generates the review list (the fix/* scripts are included automatically). The Watch DF Releases workflow appends the checklist to its job summary when it detects a new release.
| popup->text = message; | ||
| popup->color = color; // Doesn't do anything anymore? Popups are always [C:7:0:0] gray text | ||
| popup->bright = bright; // See: https://dwarffortressbugtracker.com/view.php?id=12672 | ||
| // DF-MITIGATION: the bright flag has no effect due to a DF bug; keep it set |
There was a problem hiding this comment.
Not sure this is really a mitigation, since what's happening here is that DF ignores the color values we're passing, but we still pass them because eventually it will start respecting them again. Also, this technically applies to the color field too, not just bright (which this new comment incorrectly states).
That being said, once it does get fixed, we'll want to remove these comments, so perhaps this still serves a purpose.
There was a problem hiding this comment.
Good catch. folded the pre-existing color comment into the marker so it covers both fields, and updated the convention doc to clarify that markers are also appropriate for sites whose behavior merely depends on a defect (like this one, the point is flagging it for review on new DF releases, whether or not code needs to change). Pushed as 6b401ab.
b21d2dd to
97c4673
Compare
f718770 to
6b401ab
Compare
2 participants
Summary
DFHack works around a number of defects in DF itself, and those mitigations may need adjusting or removal when Bay 12 ships a fix. This PR adds a lightweight, self-maintaining checklist for that review:
DF-MITIGATION:comment marker convention — mitigations are tagged where they live in the code, so the checklist can't drift away from the implementation. New mitigations get marked as they're added; removing one removes it from the checklist automatically.ci/list-df-mitigations.py— generates a markdown checklist from the markers. Thefix/*scripts (andfix-ster/fixnaked) are included automatically since they are all DF bug mitigations by definition; their descriptions come from the docs':summary:fields.develop(with submodules) and appends the checklist to the job summary. This gives the release coordinator a "soft reinvestigate" signal on every new release, using nothing but free-tier Actions features.release-process.rstgained a "New DF releases" section describing the review step.site_idfallback, DF bugs 1416/1871/6330/6273/12672/12721, slab category, caged pets, dismissed viewscreens). More can be marked incrementally.Sample generated output (current tree):
Open questions for reviewers:
DF-MITIGATION:) — happy to change to whatever the team prefers.Test plan
ci/list-df-mitigations.pyruns locally and produces the checklist (10 code sites + 31 fix scripts)if: env.BUILDID)